Voici quelques informations me concernant (pour peu que cela vous intéresse) :

Mon approche pédagogique repose sur quelques principes, que j’ai essayé de mettre en oeuvre dans cet ouvrage :

Aucune connaissance particulière {l’http://www.uml.org/[d’UML™] n’est nécessaire, même si j’y fais référence à plusieurs endroits pour les étudiants qui connaissent cette notation (quasiment enseignée partout maintenant comme langage de modélisation). Il s’agit d’un parti pris prenant en compte plusieurs points :

Vous trouverez en fin d’ouvrage un ensemble de liens utiles (cf. Liens et références utiles) et de références (cf. Références). Sinon, vous pouvez aussi constatez les évolutions de l’intérêt pour SysML™ grâce aux "trends". Voici les dernières tendances au moment où nous écrivons ces lignes[2] :

À noter également que l’OMG™ a réalisé en 2009 une enquête sur l’utilisation de SysML™ (cf. [OMG2009]) dont voici deux extraits :

Cet ouvrage est tout à fait utilisable dans le cadre des ces cours. Pour STI2D, seul un sous-ensemble des diagrammes de SysML™ a été retenu. Les élèves et les enseignants du bac STI2D pourront trouver dans ce document des éléments utiles sur ces diagrammes :

Ces 6 diagrammes sont tous traités dans cet ouvrage à un niveau qui devrait correspondre à l’utilisation qui en est faite en STI2D.

Ils servent trois objectifs principaux inscrits au programme et dont les élèves pourront également trouver des éléments de réflexion :

L’Union des Professeurs de Sciences et Techniques Industrielles (UPSTI) prépare à l’heure où nous écrivons ces lignes un document de cadrage en terme de méthodologie et de démarche. Nous n’insisterons donc pas sur ces aspects, mais donnerons quelques pistes dans le chapitre commun sur les conseils d’enseignement (cf. Pédagogie).

Notons que dans ce cadre-là, les 9 diagrammes sont utilisables même si pour l’instant les diagrammes paramétriques et de paquetages sont un peu mis en retrait.

Les questions et exercices de fin de chapitres de la partie notation seront peut-être d’un niveau plus avancé pour servir véritablement d’exercices, mais pourront amener à une réflexion encadrée par l’enseignant.

Le système CMS (crash management system) est un système distribué de gestion d’accidents qui est responsable de la coordination et de la communication entre un coordinateur présent dans une caserne de pompiers (appelé FSC pour Fire Station Coordinator) et un autre présent dans un poste de police (appelé PSC pour Police Station Coordinator) afin de gérer une crise dans un délai raisonnable.

La communication interne entre les membres de la police (y compris le PSC) est en dehors du domaine qui nous intéresse ici (la gestion de crise). La même hypothèse s’applique aux communications internes ou avec des acteurs externes côté pompiers (y compris le FSC). Les informations concernant la crise ainsi que tout ce qui a trait aux tâches des coordinateurs sont mises à jour et maintenues pendant et après la crise.

Il n’existe pas de base de données centrale; caserne de pompiers et police ayant leur base de données respectives distinctes et seulement accessible aux autre à travers le système CMS. Chaque processus de coordination est donc en charge de l’ajout et la mise à jour des informations dans sa base de données respective.

CMS commence à fonctionner au moment où une crise donnée a été détectée et déclarée à la fois à la caserne de pompiers et au poste de police.

Toutes les caractéristiques des différents acteurs sont détaillées ci-dessous.

Dans un axe horizontal, j’ai différencié quatre grands points de vue :

Ces différents points de vue ne doivent pas être confondus avec les différentes phases de développement (cf. paragraphe suivant). Ils sont plutôt à rapprocher de la notion de préoccupation. C’est ainsi que j’ai choisi de distinguer trois points de vue qui se retrouvent souvent en modélisation : le point de vue des exigences qui permet de se focaliser sur les besoins des clients ; le point de vue structurel qui permet de se focaliser sur les différents composants du système ; et le point de vue comportemental qui permet de se focaliser sur le comportement du système. Ces trois points de vue n'étant pas indépendants les uns des autres, j’ai intégré un quatrième point de vue transversal.

Dans un axe vertical, j’ai différencié quatre grandes phases du cycle de vie du développement :

Il s’agit ici classiquement des grandes étapes de développement d’un système. On pourrait être surpris par l'étape que j’ai appelé « organisation ». C’est une étape que je considère importante, particulièrement pour l’enseignement. Avant toute activité de modélisation ou de même de développement, il convient en effet de s’organiser en termes de choix d’outils, choix d’environnement, etc. Cette étape est souvent négligée par les étudiants. C’est pour cela que j’ai décidé de faire figurer cette étape de manière explicite. Bien sûr dans une organisation existante cette étape sera contrainte par les habitudes « maison ».

Que ce soit généralement en terme de cycle de développement ou historiquement, l’Ingénierie Système arrive avant l’Ingénierie Logicielle. Les ingénieurs systèmes ont donc une longue expérience et des pratiques bien ancrées.

On parle de système complexe lorsque l’on a affaire à un ensemble d'éléments humains et matériels en relation avec :

On parle aussi de Système de systèmes quand un système :

Toute la question que l’Ingénierie Système cherche à résoudre est : comment passer des exigences au système de la façon la plus efficace possible (cf. IS : problème).

Pour cela l’Ingénierie Système est découpée en plusieurs analyses, chacune avec un but bien particulier :

Le but de ces analyses est d’arriver à combler le gap entre le système à développer et ses spécifications (cf. IS : solution).

Voici à quoi pourrait ressembler la fiche d’identité de SysML™ :

La figure suivante, tirée de la spécification, résume bien les liens entre SysML™ et UML™, à savoir que SysML™ reprend une partie seulement des concepts d’http://www.uml.org/[UML™] (appelée UML4SysML) en y ajoutant des concepts nouveaux.

SysML™ propose de couvrir la modélisation d’un système en 9 diagrammes. Ces diagrammes couvrent les aspects structurels et comportementaux du système ainsi que les exigences. Le diagramme suivant présente cette organisation en faisant au passage le lien avec ceux d’http://www.uml.org/[UML™] :

Le nom de ces diagrammes revenant souvent dans ce document, nous utiliserons souvent leur version abrégée (uc pour "diagramme des UC" par exemple). Ces abréviations, sont définies dans la spécification (cf. note suivante).

SysML™ n’est pas une palette de dessins et d'éléments de base servant à faire des diagrammes. Il existe une représentation graphique des éléments modélisés en SysML™. Elle est importante car elle permet de communiquer visuellement sur le système en développement, mais du point de vue du concepteur, c’est le modèle qui importe le plus.

C’est pourquoi nous vous recommandons de ne jamais "dessiner" des diagrammes SysML™ [5], mais d’utiliser des outils dédiés (cf. Outils SysML). Ils respectent en général la norme OMG SysML v1.3 (bien qu’il faille se méfier).

Un des intérêts de la modélisation est de faciliter la communication, notamment au travers des diagrammes et leur aspect graphique et synthétique. Un dessin est donc un plus par rapport à du texte. Néanmoins, il ne faut pas se contenter d’un simple dessin pour au moins deux raisons importantes :

Un modèle est une sorte de base de donnée qui regroupe des éléments issues de différents points de vue (saisis le plus souvent au travers de diagrammes). Un diagramme est une vue partielle du modèle (donc incomplète). Le modèle est la vraie plus value car il va permettre de détecter les incohérences sur les exigences, les problèmes de complétude, lancer des analyses, faire des transformations vers d’autres langages ou formats, etc. Par exemple dans un outil de modélisation il y a une grande différence entre supprimer un élément d’un diagramme (on parlera alors de "masquer" un élément d’un diagramme) et supprimer un élément de modèle (ce qui aura pour effet de supprimer cet élément de tous les diagrammes où il était présent).

Voici deux exemples de non respect de la notation qui illustre le type d’erreur que l’on trouve souvent dans les modèles qui circulent sur Internet ou même parfois dans certains livres.

Il existe un certain nombre d’outils permettant de réaliser des modèles SysML. Voici une liste non exhaustive :

Vous trouverez sur Internet des comparatifs et des avis à jour sur les outils.

Ce que je voudrai souligner ici c’est l’importance du modèle comme "dépôt" (je préfère le terme anglais de repository) d'éléments de base en relation les uns avec les autres. C’est toute la différence entre le dessin et le modèle.

Dans le cadre de notre exemple fil rouge, nous utilisons l’outil TOPCASED.

Abordons quelques principes généraux de SysML™, c’est à dire des éléments indépendant d’un diagramme en particulier :

Dans l’exemple ci-dessous, le diagramme "Context_Overview" est un Block Definition Diagram (type bdd) qui représente un package, nommé "Context".

Pour ceux qui cherchent à étudier un diagramme en particulier voici un plan de cette section (nous utilisons ici le "plan" vu lors de l’introduction de la La carte de base) :

Nous sommes des défenseurs des principes [DRY] et [TDD]. Nous allons donc réaliser nos diagrammes dans un outil et non "à la main" (de simples dessins). Nous choisissons ici l’outil TOPCASED pour des raisons que nous expliquerons ailleurs. La version utilisée pour réaliser les exemples de cette section est la version 5.2.

Un outil SysML™ seul ne suffit pas (cf. Outils). Il faut penser à la documentation (cf. Génération de documentation).

Il s’agit ici de décrire le contexte et d’identifier les principaux cas d’utilisation du système.

Chaque cas d’utilisation sera précisé (seq et act). Les données métier seront alors identifiées pour construire le modèle d’architecture logique (bdd et ibd) complété par la description des comportements complexes (stm). Enfin le modèle d’architecture physique permettra de déterminer les aspects déploiement et constructions physiques d'équipements/

Afin de consolider les différents modèles, les liens de traçabilité qui n’auront pas été déjà décrit [7] seront rajoutés en insistant sur les liens :

Nous insistons dans l’ensemble de nos formations sur les approches test-driven, alors nous montrons dans cette section comment participer à la qualité du développement d’un système en formalisant (par exemple avec des diagrammes de séquence de scénarios à éviter) les test et les jeux de test.

Je recommande vraiment l’utilisation d’outils (même de dessins, mais dédié à) SysML™. Ils respectent en général la norme OMG SysML v1.3 (bien qu’il faille se méfier). Eviter de "dessiner" des diagrammes.

Par contre la norme permet de faire des adaptations graphiques (cf. la discussion http://www.realtimeatwork.com/2011/08/is-sysml-too-abstract/).

Par exemple dans ce diagramme les blocs ne respectent pas la syntaxe graphique de SysML™ :

Pour rappel, la notation jmb : Personne permet de représenter un objet (une instance d’une classe ou d’un bloc). C’est donc une notation utilisée par exemple dans les participants d’un diagramme de séquence ou encore les parties d’un diagramme interne de bloc.

Donc dans le diagramme ci-dessus, l’acteur est correct (on peut mettre des acteurs dans un bdd, cf. OMG SysML v1.3 p.32), par contre les objets Block : … est une erreur de notation.

Plusieurs problèmes de non respect de la notation :

Version 1.3 et disponible à l’URL: http://www.sysml.org/docs/specs/OMGSysML-v1.3-12-06-02.pdf

(en lien avec la question précédente)

Les changements notables par rapport à la 1.2 concernent :

La version 1.3 a précisé la sémantique des ports et abandonne le concept de flow specification au profit d’une description via un bloc possédant des flow properties (cf. Flow properties).

Ainsi :

Les informations sur la certification sont sur le site dédié de l’OMG™.

La certification (qui coûte environ 300€ par niveau) permet de garantir que celui qui la possède maîtrise la notation. Il faut actuellement s’inscrire via le site de Pearson Vue.

Non. Le lien de containment est en fait une action qui place le "contenu" dans le "contenant". Dans TOPCASED, le diagramme laisse les liens précédents à l'écran, mais dans le modèle, c’est bien le dernier containment réalisé qui est pris en compte. Dans la figure ci-dessous le lien A-C a été "dessiné" après celui B-C.

(En lien avec la question précédente)

L’organisation SysML™ des requirements est en fait un arbre. Pour réaliser ce "partage" certains utilisent un lien <<copy>> pour créer plusieurs copies d’un même requirement. Personnellement je n’aime pas cette solution.

Techniquement oui (<<satisfy>> étant dérivé de <<dependency>>), mais ça n’a pas beaucoup de sens que de dire qu’un besoin est satisfait par un autre. Il s’agit le plus souvent d’un lien <<deriveReqt>>.

La norme n’impose pas de sémantique précise à <<deriveReqt>>. Il y a généralement deux interprétations.

Autre exemple respectant 1 mais pas 2 : "Le véhicule doit posséder 4 roues." est dérivé de "Le véhicule doit se déplacer sur route." En effet, un aéroglisseur répondrait aussi l’exigence initiale et n’a pourtant pas de roues.

Quant au <<refine>> il est utilisé pour indiquer qu’un élément de modèle (qui peut être lui-même un requirement) est un raffinement (au sens niveaux d’abstraction, du plus abstrait au plus concret) d’un requirement. Par exemple, un use case ou un diagramme d’activité peut être un raffinement d’une exigence fonctionnelle (textuelle par exemple).

Il est utilisé pour indiquer que l’on souhaite conserver un lien de traçabilité entre les éléments (par exemple entre un élément de modélisation et un document). Il est recommandé d’utilisé une de ces versions plus précises (<<deriveReqt>> ou <<satisfy>> par exemple).

Comment SysML™ permet de vérifier et de valider les exigences ?

La validation d’une exigence est de la responsabilité des parties prenantes. À partir de la spécification des exigences, ils valident qu’il s’agit bien du bon produit à construire. Typiquement, le diagramme des exigences sert de base à cette validation.

La vérification d’une exigence est de la responsabilité de l’ingénieur système et/ou de l’analyste système. C’est à eux de montrer la correspondance entre les éléments constituant du système et les exigences spécifiées. C’est principalement pour cette activité que sont utilisés les relations <<satisfy>> et <<verify>>.

Tout simplement à relier les autres diagrammes à ce cas d’utilisation. Par exemple le comportement du système, l’architecture, etc. (les solutions) pourront être reliées (<<satisfy>>) à ce cas. Il faut aussi ne pas perdre de vue qu’un diagramme peut évoluer. On pourra très bien rajouter au diagramme des cas non encore pris en compte comme Transporter le système, Recycler le système, etc.

La définition de la norme OMG SysML v1.3 :

Pour la comprendre il ne faut pas utiliser le Larousse français (qui rend presque le caractère réciproque obligatoire), mais plutôt la comprendre dans son acceptation informatique (comme dans "Interaction Homme-Machine"). Par exemple un message (appel de méthode) d’un élément vers un autre dans un diagramme de séquence est appelé en SysML™ une interaction.

SysML™ permet de préciser le caractère réciproque ou non de l’interaction par exemple entre un Acteur et un Cas d’utilisation :

On pourrait les considérer comme des acteurs en se fiant à la définition (cf. Acteurs) et en les associant à des environmental entities. Mais elles sont échangées avec les entités de l’environnement, ce qui n’est pas la même chose. Autrement dit, il faut indiquer qui fournit les matières premières et qui recueille les matières produites éventuellement en tant qu’acteurs, pas les matières elles-même, qui seront représenter comme des flux échangés ou des blocs. Eventuellement on peut les retrouver dans le diagramme de contexte ou encore dans un diagramme structurel comme le diagramme de bloc interne.

Pour alimenter le débat, je renvois aux exemples donnés par Loïc Féjoz lors de la journée UPSTI. Voici un diagramme classique FAST :

On pourrait croire que ces schémas sont identiques mais pas du tout. SysML™ présente juste l’organisation du modèle et non l’arbre d’appel. De plus, FAST a tendance à focaliser sur une solution unique alors que SysML™ permet de repousser ce choix voir d’explorer des alternatives.

Pour rappel le join est utilisé pour représenter la synchronisation (le "rendez-vous") et représente donc une conjonction "ET". Mais le comportement par défaut pouvant être modifié par un <<joinSpecification>>, on peut indiquer un "OU" pour signifier l’attente d’un seul des deux jetons. Mais justement le fusion est là pour ça normalement. Ces 2 concepts étant issus d’http://www.uml.org/[UML™], il nous faut nous référer à la norme de ce dernier:

Il n’y a donc sémantiquement aucune différence.

On lit souvent qu’il n’y a pour un système ou un composant "qu’un seul état actif à la fois".

Du point de vue structurel, si l’on considère que l'état à un instant t d’un composant est représenté par la valeur de ses attributs à cet instant, alors cette composition est unique. Néanmoins cela prête souvent à confusion avec le fait qu’un composant dont le comportement est décrit par une machine à état avec des régions concurrentes peut se retrouver dans plusieurs états (SysML™ du coup) en même temps.

Il faut donc bien faire la différence entre :

En automatique, la notation la plus connue pour représenter la dynamique d’un système est le Grafcet. Il semble qu’il existe une synthèse du passage Grafcet ⇒ diagramme d'état. J’attends de le trouver pour l’intégrer ici. Car sans en être un spécialiste, ce que j’en ai lu me fait plutôt penser à un diagramme d’activité (notamment par leur proximités à tous les deux avec les Réseaux de Petri).

Quelques autres questions que je laisse à votre sagacité :

SysML™ n’est pas un programme qu’on installe. Il existe de nombreux outils qui chacun possède sa propre façon d'être installé sur votre machine (en fonction de votre système d’exploitation, si c’est un plugin, etc.).

Les diagrammes SysML™ ne sont que des dessins, des représentations graphiques, ils ne s'exécutent donc pas. Bien sûr de nombreux travaux et outils portent sur les modèles exécutables. Il s’agit alors pour un outil de proposer de reproduire la dynamique d’un diagramme. Il s’agit en général de diagramme de comportement (par exemple une machine à état) pour lequel l’outil propose de simuler l’arrivée d'événement et de reproduire (plus ou moins graphiquement) le comportement modélisé (par exemple le franchissement d’une transition).